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COMMON MANAGEMENT INFORMATION BASE (MIB) 

TECHNICAL FIELD OF THE INVENTTOM 

This invention relates generally to telecommunications 
systems, and more particularly to a common management 
information base (MIB) for a network element in a 
telecommunications system. 

BACKGROUND OF THE INVENTION 

1®l®communicat ions systems include customer premise 
equipment (CPE) , local loops connecting each customer 
premise to a central office (CO) or other node, nodes 
Providing switching and signaling for the system, and 
internode trunks connecting the various nodes . The 
customer premise equipment (CPE) includes telephones, 
modems for communicating data over phone lines, computer 
and other devices that can directly communicate video, 
audio, and other data over a datalink. The network nodes 
include tradition circuit -switch nodes, which have 
transmission pass dedicated to specific users for the 
duratxon of a call and employ continuous, fixed-bandwidth 
transmission, as well as packet -switch: nodes that allow 
dynaraic bandwidth, dependent on the application. The 
transmission media between the nodes may be wireline, 
or a combination of these or other transmission 

medias . 

In a telecommunication system, the nodes are managed 
by standardized management protocols such as Transaction 
Language One (TL-1) , simple network management protocol 
(SNMP) , Common Management Information Service Element 
(CMISE) , and the like. Generally speaking, each of these 
management protocols includes a protocol agent and abject, 
model. The agent is responsible for parsing the external 
management commands and maintaining communication sessions 
with external management stations or users. The object 
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model is a management information base (MIB) . The MIB is 
a data structure built for a specific management protocol 
to exchange the management information between a node and 
external management stations. 

Multiple protocol nodes that handle disparate types of 
traffic are typically required to support multiple 
management protocols such as TL-1, SNMP, and/or CMISE. 
Provision of multiple databases to support the different 
protocols requires large amounts of resources to implement 
the databases and maintain data integrity across the 
databases. One attempt to use a single database for 
multiple protocols configured the database in accordance 
with one protocol and used a protocol adapter for a second 
protocol . The protocol adapter translates protocol 
messages from the second protocol to the first protocol and 
responses back to the second protocol . Due to the 
incompatibility between management protocols, however, the 
adapter is a complex component that is expensive to 
implement. In addition, the adapter is inefficient due to 
the protocol translations, which slow down response time. 
Other attempts to support multiple management protocols 
with a sxngle dataJDase provided only LitnitedL functionality 
for one of the protocols while creating special commands 
for the other. This solution is expensive to implement and 
provides only a partial solution. 

SUMMARY OF THE INVENTION 

The present invention provides a common management 
information base (MIB) that substantially eliminates or 
reduces problems associated with previous methods and 
systems. In particular, the common MIB provides a layer of 
abstraction to isolate internal data representations from 
data representations made externally to a network element. 
This allows a network element to have a single, consistent 
internal representation of data, and at the same time. 
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support multiple different external interfaces for 
management . 

In accordance with one embodiment of the present 
invention, the common MIB or other data store includes a 
set of data structures, a set of entity classes, and an 
interface object. The data structures each store data for 
an entity type. The entity classes each include specific 
functionality for an entity type. The interface object 
includes base functionality for the entity types. An 
interface is operable to generate an entity interface by 
loading the interface object with an entity class for an 
entity type and to access the data structure for the entity 
type using the entity interface. 

More specifically, in accordance with a particular 
embodiment of the present invention, the data structures 
are stored in non-volatile memory, such as relational 
database tables. m this and other embodiments, the 
interface accesses the data structures by executing the 
entity interface. The entity interface is initially 
populated, executed, and responded to by executing function 
C3.11s within the entity ir 1 te 2 rfa.ce. 

Technical advantages of the present imrention: tncltide 
providing a protocol independent MIB for managing multi- 
protocol network elements within a telecommunications 
network. In particular, the common MIB provides a layer of 
abstraction to isolate data representations internal to the 
network element from data representations made externally 
to the network element. Moreover, the modular design of 
the common MIB allows for time and cost efficient testing, 
integration and packaging of the system. 

Another technical advantage of the. present invention 
includes providing an improved data store for storing data, 
representations of a network element . In particular, the 
MIB includes a collection of managed entities (MBs) that 
includes a class definition and data attributes stored in 



,CX)76129A1J_> 




10 



15 



20 



25 



30 



3NSDOC1D-. <WO. 



WO 00/76129 PCT/US00/15S53 

4 

non-volatile memory. The class definitions are 
instantiated to generate an interface for communicating 
with the data attributes in the non-volatile memory. In 
this way, a separate instance need not be continuously 
maintained for each ME. Therefore use of resources is 
optimized. 

Other technical advantages of the present invention 
will be readily apparent to one skilled in the art from the 
following figures, description, and claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 

For a more complete understanding of the present 
invention and its advantages, reference is now made to the 
following description taken in conjunction with the 
accompanying drawings, wherein like reference numerals 
represent like parts, in which: 

FIGURE 1 is a block diagram illustrating a common 
management information base (MIB) in accordance with one 
embodiment of the present invention; 

FIGURE 2 is a block diagram illustrating relationships 
between interface, base and managed entities (ME) classes 
in the common MIB of FIGURE L in acrcordarice with: ■ one 
embodiment of the present invention; 

FIGURE 3 is a block diagram illustrating the ME 
command object of FIGURE 1 in accordance with one 
embodiment of the present invention; and 

FIGURE 4 is a flow diagram illustrating a method for 
performing a management transaction with the common MIB of 
FIGURE 1 in accordance with one embodiment of the present 
invention . 
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DETAILED DESCRIPTION OF THE im^ENTTOM 

FIGURE 1 illustrates management components of a multi- 
protocol network element (NE) 10 in accordance with one 
embodiment of the present invention. in this embodiment, 
the ME 10 includes Internet Protocol (IP), Asynchronous 
Transfer Mode (ATM) , and Synchronous Optical Network 
(SONET) layers and functionality and can communicate over 
local area networks (LANs) as well as transmission line 
trunks. IP and other suitable traffic from the LAN is 
converted to ATM traffic for transmission by the SONET 
layer whxch forms the physical interface for the 
transmission line trunks. 

The NE 10 supports Common Management Information 
service Element (CMISE) , simple network management protocol 
(SNMP), and Transaction Language One (TL- 1 ) management 
protocols. A CMISE management station 14, SNMP management 
station 16, and TL-1 management station 18 are coupled to 
the NE 10 by a local area network (LAN) , wide area network 
(WAN), or other communication link 20. Accordingly, the 

management stations 14, 16, and 18 may be local or remote 
from the NE 10. 

Referring to FIGURE 1 , the NE 10 includes a. plurality 
of protocol-specific subsystems 30-, a common management 
information base (MIB) 32, and a set of low level software 
drivers 34. Each subsystem 30 includes a protocol -specific 
agent 40 and a data model 42. The protocol-specific agent 
40 parses external management commands and maintains 
communication sessions with external management stations or 
users. The data model 42 maps protocol-specific management 
transactions received from a management station to a common 
management protocol for processing by the common MIB 32. 
Accordingly, all protocol -specific processing is local to 
the subsystems 30, allowing the common MIB 32 to be 
protocol independent . 
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For the embodiment of FIGURE 1, the subsystems 3 0 
include a CMISE subsystem 50 for supporting the CMISE 
management station 14, a SNMP subsystem 52 for supporting 
the SNMP subsystem 16, and a TL-1 subsystem 54 for 
supporting the TL-1 management station 18. The CMISE 
protocol is an OSI defined management service containing an 
interface with a user, specifying the service provided, and 
a protocol, specifying the protocol data unit format and- 
the associated procedures. In the CMISE subsystem 50, the 
data model 42 is a Guideline for Definition of Managed 
Object (GDMO) which is an OSI specification for defining a 
management information structure used in the CMISE 
environment. SNMP is an IETF defined network management 
protocol including definitions of a database and associated 
concepts. In the SNMP subsystem 52, the data model 42 is 
an ent ity-relat ionship model in accordance with SNMP 
standards. TL-1 is an ASCII or man-machine management 
protocol defined by Bellcore and typically used to manage 
broadband and access equipment in North America . In the 
TL-1 subsystem 54, the data model 42 includes a data 
dictionary for access identifiers (AIDs) and commands in 
accordance with TL-1 standards* In th±s way,, the data 
models 42 only occupy a small amount of memoiry resources in 
the network element 10 and keep protocol -specif ic 
processing local to each subsystem 50, 52, or 54. 

The common MIB 32 includes an application interface 
(API) 60, a transaction queue 62, a set of response queues 
64, and a database 66. The API 60 provides generic 
management functionality to the CMISE, SNMP, and TL-1 
subsystems 50, 52, and 54. As described in more detail 
below, the common MIB 3 2 provides an efficient and flexible, 
component to allow a telecommunications device to be 
controlled and monitored by external interfaces using 
specific management protocols. 
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The API 60 includes an interface object 70 for each 
subsystem 30 registered with the API 60, one or more 
command objects 72 for each registered subsystem 30, and a 
set of managed entity (ME) classes 74 to which protocol - 
specific transactions are mapped by the subsystems 30. As 
described in more detail below, by applying object-oriented 
modeling techniques, the information of the hardware and/or 
software resource is encapsulated into the class 
definition, which then provides service interfaces to other 
software components. 

The interface objects 70 are each accessed by a 
cc)^^®sponding subsystem 30 to communicate with the API 60. 
The interface object 70 for a subsystem 30 is created by 
the API 60 upon registration by the subsystem 30. At that 
time, the subsystem 30 requests a number of command objects 
72 that can be simultaneously used by the subsystem 30, 
which are generated and allocated by the API 60. 

The command objects 72 each encapsulate a base class 
76 for the ME classes 74 . The ME classes 74 each include 
specific functionality for an ME type. The base class 76 
includes function calls, methods, parameters, behaviors, 
and ocher attributes shared by ail or ac least some of. the 
ME classes 74 . Accordingly, each command object 72 
includes base functionality that is used by the ME classes 
74 to access the database 66 or perform functions within 
the common MIB 32, such as communicating with the low level 
software driver 34 in order to determine or change the 
state of hardware in the NE 10 . As described in more 
detail below, portions of the base class 76 may be 
overwritten by specific ME classes 74 when forming an ME 
command object 78. The ME command object 78 forms an 
interface for accessing ME attributes and functions in the 
database 66 and the low level software driver 34 . in this- 
way, each ME class 74 may select functionality from the 
base class 76 to be used in accessing the corresponding ME. 
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The transaction queue 62 stores ME command objects 78 
' generated by the API 60 in conjunction with the subsystems 
30 for processing by the common MIB 32. In one embodiment, 
the transaction queue 32 is a first-in-first-out (FIFO) 
buffer that serializes processing in the common MIB 32 to 
prevent multiple operations from being performed at the 
same time, and thus prevent corruption of data, data 
contention, and race conditions within the common MIB 32. 

In the database 66, attributes for each of the ME 
types are stored in ME data structures 80. Preferably, the 
data structures are non-volatile structures to ensure data 
integrity. In one embodiment, the database 6 6 is a 
relational database and the ME data structures 80 are 
relational database tables. It will be understood that the 
ME attributes may be otherwise suitably stored without 
departing from the scope of the present invention. 

The response queues 64 store responses to transactions 
processed by the common MIB 32. In one embodiment, the 
response queues 64 include a discrete queue for each 
subsystem 30. In this embodiment, each subsystem 30 reads 
responses in its corresponding queue 64 and extracts data 
for generating a protocol -specific: response for 

transmission, to the management station originating the 
transaction. It will be understood that responses to 
transactions may be otherwise made available by the common 
MIB 32 to the subsystems 30. 

FIGURE 2 illustrates details of the object interfaces 
70, command objects 72, and ME class objects 74 in 
accordance with one embodiment of the present invention. 
In this embodiment, the objects 70, 72, and 74 are each 

fully instantiated objects encapsulating both data and 
behavior and inheriting data and behavior from parent 
classes. 

Referring to FIGURE 2, the interface object 70 
includes client callback, client quality of service (QoS) , 
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client command objects, and client interface parameters. 
The interface object 70 calls an associated command object 
72 in the API 60. 

The command objects 72 include command methods, 
command correlation, command errors, and command 
parameters. The command object 72 further inherits 
attributes of the base class 76. As previously described, 
the base class 76 includes common ME attributes and common 
ME methods . 

The ME class objects 74 each include functionality 
associated with a particular ME type. Such functionality 
includes ME attributes, methods, parameters, and behavior 
for the ME type. Attributes of an ME class 74 are 
inherited by the command objects 72 through the base class 
76 to generate the ME command object 78. As previously 
described, the ME command object 78 provides an interface 
for accessing data and functionality in the common MIB 32. 

FIGURE 3 illustrates details of an ME command object 
78 in accordance with one embodiment of the present 
invention. In this embodiment, the ME command object 78 is 
self contained. Any system resources obtained, such as 
memory or buffers are "owned" by th.e. object 78 and released.. 
when the object 78- is destructed. It will be understood 
that the ME command object 78 may be otherwise suitably 

implemented for accessing data and attributes and common 
MIB 32. 

Referring to FIGURE 3, the ME command object 78 
includes a public data section 100 and a private data 
section 102. The public data section 100 of the ME command 
object 78 is accessible by the client subsystem 30. The 
public data section 100 includes method functions that hide 
the structure, data manipulation, and allocation details 
from the client subsystem 30. In addition, the methods in 
the public data section 100 respond to affects of the 
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methods chosen and perform any command integrity checks 
required. 

In one embodiment, the methods may include inline 
functions, particularly those used for setting and 
retrieving small (typically integer) attribute values. 
Attribute methods, for example, will be available to 
populate get/set/create commands, and to retrieve values 
resulting from the same. Constructor, invoker, and 
releasor methods will be used to create, execute, and 
destroy ME command objects 78. Behavior methods are used 
by common MIB 32 to execute the commands. 

The private data section 102 of the ME command object 
78 includes data to complete the command. The response 
data for successful or error return will also be contained 
in the private data section 102. In one embodiment, any 
miscellaneous system resources dynamically allocated for 
the command are retained in the private data section 102. 
This type of allocation is preferably minimized. 

FIGURE 4 is a flow diagram illustrating a method for 
performing a management transaction in accordance with one 
embodiment of the present invention. In this embodiment, 
the tra ns action may be received, from any one of the 
plurality of management stations in a management protocol 
supported by the NE 10. 

Referring to FIGURE 4, the method begins at step 110 
in which subsystem 30 receives a transaction in a specific 
management protocol. Next, at step 112, the subsystem 30 
maps the protocol specific transaction to a protocol 
independent ME class 74 which will be used by the common 
MIB 32 to perform the transaction. Mapping may include any 
suitable type of transaction, conversion, or associations. 
Accordingly, protocol specific processing is retained at 
the subsystem level . 

At step 114, the subsystem 30 opens a communications 
session with the API 60. As previously described, the 
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session may be opened by calling an interface object 70 in 
the API 60 corresponding to the subsystem 30. Proceeding 
to step 116, the subsystem 30 requests a command object 72 
from the API 60. The subsystem 30 may use any number of 
command object 72 at a time up to the number allocated to 
the subsystem 30 in the API 60. 

At step 118, the subsystem 30 identifies the protocol 
independent ME class 74 to which the protocol specific 
transaction was mapped. Next, at step 120, the API 60 
generates and returns an ME command object 70 to the 
subsystem 30. As previously described, the ME command 
object 78 includes attributes of the base class 76 and the 
ME class 74. Portions of the ME class 74 may overload 
portions of the base class 76 to provide specific 
functionality in place of base functionality. At step 122, 
the subsystem 30 populates the ME command object 78 based 
on the transaction by calling command functions stored in 
the ME command object 78. 

Proceeding to step 124, the populated ME command 
object 78 is transferred to the transaction queue 62 in 
common MIB 32 for processing. The transaction queue 32 
serializes processing in common. MIB 32 to prevent, data 
contention between co -pending ME command objects 78. At 
step 126, the ME command object 78 is removed from the 
transaction queue 62 and executed by the common MIB 32. 
During execution, the ME command object 78 accesses the 
corresponding ME table 80 and/or performs functions in 
accordance with functions, behaviors, and parameters in the 
ME command object 78 which are based on the transaction. 

Next, at step 128, the common MIB 32 generates a 
response in accordance with the function calls in the ME 
command object 78. At step 130, the response is 
transferred to the response queue 64 for the subsystem 30 
that generated the ME command object 78. Next, at step 
132, the subsystem 30 extracts data from the response and 
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generates a protocol specific response for transfer back to 
the requesting management station. At step 134, the 
subsystem 3 0 releases the command object 72 back to the API 
60. In this way, the common MIB 32 provides a layer of 
5 abstraction to isolate data representations internal to the 

network element 10 from data representations made 
externally to the network element 10. Data integrity and 
consistency is guaranteed as only a single database is 
maintained. 

10 Although the present invention has been described with 

several embodiments, various changes and modifications may 
be suggested to one skilled in the art. It is intended 
that the present invention encompass such changes and 
modifications as fall within the scope of the appended 
15 claims. 
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WHAT IS CLAIMED IS; 

1. A network element, comprising: 

a first subsystem operable to receive management, 
transactions in a first management protocol and to map the 
management transactions to a common management protocol; 

a second subsystem operable to receive management 
transactions in a second management protocol and to map the 
second transactions to the common management protocol; 

a common management information base (MIB) comprising 
a dataset and a common interface to the dataset, the 
interface comprising software stored in a computer -readable 
medium and operable to access the dataset to process 
transactions from the first and second subsystems in the 
common management protocol ; 

the dataset comprising data structures, each data 
structure storing data for a managed entity type; 

the common management information base (MIB) further 
comprising a set of managed entity classes, each managed 
entity class comprising specific functionality for a 
managed entity type; 

the common management information base (MIB) further 
comprising an interface object con?:rising base 
functionality- for the managed entity types; and 

the common interface operable to generate a managed 
entity interface by loading the interface object with a 
managed entity class for a managed entity type and to 
access the data structure for the managed entity type using 
the managed entity interface. 

2. The network element of Claim 1, wherein the data 
structures are table structures. 
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3. The network element of Claim 1, further 
comprising the common interface operable to access the data 
structure for the managed entity type by executing the 
managed entity interface. 
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4. A data store, comprising; 

a set of data structures, each data structure storing 
data for an entity type; 

a set of entity classes, each entity class comprising 
specific functionality for an entity type; 

an interface object comprising base functionality for 
the entity types; and 

an interface comprising software stored on a computer- 
readable medium, the interface operable to generate an 
entxty interface by loading the interface object with an 
entity class for an entity type and to access the data 
structure for the entity type using the entity interface. 

5- The data storage of Claim 4, further comprising 
the interface operable to access the data structure for the 
entity type by executing the entity interface. 



6. The data store of Claim 4, wherein the set of 
data structures comprise table structures. 

7. The data store of Claim 4, wherein the data 
structures comprise tables in a relational database. 

8. The data store of Claim 4, further comprising the 
interface operable to populate the entity interface by 
executing function calls within the entity interface. 

9. The data storage of Claim 4, further comprising 
the interface operable to generate a response to a 
transaction initiating generation of the entity interface 
by executing function calls within the entity interface. 
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10. A method for storing data, comprising: 

storing data for each of a plurality of entity types 
in a data structure; 

encapsulating specific functionality for each of the 
entity types in an entity class; 

encapsulating base functionality for the entity types 
in an interface object; 

in response to a request to access data for an entity 
type, generating an entity interface by loading the 
interface object with the entity class for the entity type ; 
and 

accessing the data structure for the entity type using 
the entity interface. 



11 . 


The 


method 


of Claim 


10, 


further 


comprising 


accessing 


the 


data 


Structure for 


the entity type by 


executing 


the 


entity 


interface . 








12 . 


The 


method 


of Claim 


10, 


further 


comprising 


storing data for the 


entity types 


in 


table structures . 


13 . 


The 


method 


of Claim 


10, 


further 


aoxxxpizistng 


storing data for the 


entity types in relational database 


tables . 














14 . 


The 


method 


of Claim 


10, 


further 


comprising 


populating the 


entity 


interface by 


executing function calls 


stored in 


the 


entity 


interface . 








15 . 


The 


method 


of Claim 


10, 


further 


comprising 


generating a 


response to a 


transaction 


initiating 



generation of the entity interface by executing function 
calls stored in the entity interface. 



,0076129A1J_> 





tow LEVEL SOFTWARE DRIVER 



























wo 00/76129 



PCT/USOO/15553 



2/3 



70 




78 






ME COMMAND OBJECT 



PUBLIC DATA 

ATTRIBUTE METHOOSQ CONSTRIOQRO 
ACTION MEITTOOSQ RELEASEF^) 

ERROR METHOOSQ INVOKERQ 

BEHAVIOURQ I 



100 



CLIENT DATA 



ATTRS 



PRIVATE DATA 



102 




ERROR DATA 



SCRATCHPAD 




FIG. 3 



BNSDOCID; <WO 0076129A1_I_> 





wo 00/76129 



3/3 

( START ^ 



PCT/USOO/15553 




FIG. 4 



3NSDOC1D: <WO 



0076129A1 I > 





INTERNATIONA!. SEARCH REPORT 



I' lotlonal Application No 

PCT/US 00/15553 



A, CLASSIFICATION OF SUBJECT MATTER 

IPC 7 H04L12/24 



According to intemationai Patent Classification (IPC) or to both nationai classification and IPC 



B. FIELDS SEARCHED 



Minim um documentation aearchod (classification system followed by classification symbols) 

IPC 7 H04L 



Documentation searched other than minimum documentation to the extertt that such documents are included in the fields searched 



Bectronic Hata base consulted during the intemationai search (name of data base and. where practical, search ternts used) 

EPO-Internal , WPI Data, PAJ, IBM-TDB, INSPEC, COMPENDEX 



C. DOCUMENTS CONSIDERED TO BE RELEVANT 



Category • 


Citation of document, with indication, where appropriate, of the relevam passages 


Relevant to claim No. 


X 


MAZUMDAR S ET AL: "DESIGN OF PROTOCOL 


1-6, 




INDEPENDENT MANAGEMENT AGENT TO SUPPORT 
SNMP AND CMIP QUERIES" 

INTEGRATED NETWORK MANAGEMENT. Ill 
PROCEEDINGS 3RD INTERNATIONAL SYMPOSIUM, 
18-23 APRIL 1993, 


10-12 




1993, XP000749257 




A 


the whole document 


7-9, 

13-15 









s 



Further documents are listed in the continuation of box C. 



ID 



Patent family members are listed in annex. 



* Spec«al categories of cited documents : 

•A* document defining the gemeral state of the art which is not 
considered to be of partiouiar relevaru^e 

*E* earlier document but published on or after the interruttionai 
filing date 

T* document which may throw doubts on priority ciaim(s> or 
which is cited to establish the publication date of another 
citation or other special reason (as specified) 

*0* document refenirtg to an oral dacloaure. uae^ exhibctian or 
other means 

*P* document pubfished prior to the intematianai fifing date but 
later than the priority date darned 



"T* later document published aftw the intemationai filir^ date 
or priority date and not in conflict with the application but 
cited to understand the principle or theory underlying the 
invention 

•X* document of particulaf retevarwo; the claiined invention 
cannot be considered novel or cannot be considered to 
involve an inventive step when the document is taksn alone 

"T* document of particular felevance; the claimed mvenhon 

carmot be considered to involvo an inventive step w hen t he 

document is combined with or» or more other 

menta, such combinaliQn being obvious to a personswBed 

in theaiL 

document member of the same patenttomrfy 



Dale o! the actual completion of the intemationaJ search 

24 October 2000 



Date of mailing of the international search report 

07/11/2000 



1 



Name and mailing address of the ISA 

European Patent Office, P.B. 5816 Patentlaan 2 
NL - 2280 HV Rijswijk 
Tel. (+31-70) 340-2040. Tx. 31 651 epo nl. 

Fax; (+31-70) 340-3016 



Authorized officer 



Cichra, M 



Form PCT/lSA/210 (aaoood ohoet) (July 1992) 
BNSIXXID: <WO 0076129A1_I_> 



page 1 of 2 




INTERNATIONAL SEARCH REPORT 



(r ationaf Application No 

PCT/US 00/15553 



C.rContlnuatJon) DOCUMEffTS CONSIDERED TO BE RELEVANT 



goiy • I Citation of document, with in<fication.wherB appropriate, of the relevant passages 



Relevant to claim No. 



I SEDA K ET AL: "CORBA-BASED NETWORK 

OPERATION SYSTEM ARCHITECTURE" 

IEEE NETWORK OPERATIONS AND MANAGEMENT 
SYMPOSIUM, US, NEW YORK, NY: IEEE, 
vol. CONF. 10, 

15 February 1998 (1998-02-15), pages 
639-648, XP000799535 
ISBN: 0-7803-4352-2 
the whole document 

KELLER A: "TOOL-BASED IMPLEMENTATION OF A 

Q-ADAPTER FUNCTION FOR THE SEAMLESS 
INTEGRATION OF SNMP-MANAGED DEVICES IN 
TMN" 

IEEE NETWORK OPERATIONS AND MANAGEMENT 
SYMPOSIUM, US, NEW YORK, NY: IEEE, 
vol. CONF. 10, 

15 February 1998 (1998-02-15), pages 
400-411, XP000799511 
ISBN: 0-7803-4352-2 
the whole document 



1 , 2 , 4, 6 



3,5,7-15 

1-15 



US 5 764 955 A (DOOl 
9 June 1998 (1998-Oc; 
abstract 
figures 1,5,6 
claims 1-5 

column 3, line 57 -c 
column 4, line 58 -c 
column 9, line 1-14 
column 11, line 14-44 



PAUL D) 
3 ) 



jmn 4 , 1 1 ne 5 
4mn 5, line 12 



1 - 6 . 

10-12 



KOERNER E: "Design of a proxy for 

managing CHIP agents via SNMP" 

COMPUTER COMMUNICATIONS, NL, ELSEVIER 

SCIENCE PUBLISHERS BV, AMSTERDAM, 

vol. 20, no. 5, 1 July 1997 (1997-07-01), 

pages 349-360, XP004126690 

ISSN: 0140-3664 

the whole document 



1 - 6 . 

10-12 



F«m PCT/lSAy210 (oontvnjotion o# aeoond eheet) (July 1992) 



3NSOOCID: <WO 



0076129A1 I > 



. page 2 of 2 








poim PCT/ISA/210 (patani famHy annex) (July 1992) 



BNSDCXID: <WO, 



,0076129A1J_> 



THIS PAGE BLANK <usi>ro) 




